Referring initially to FIG. 1, an example Service Capability Exposure Function (SCEF) 102 is depicted. The Service Capability Exposure Function (SCEF) is a new function that is being discussed within 3GPP SA2. The SCEF is currently defined in the 3GPP Technical Report (TR) 23.708, “Architecture Enhancements for Service Exposure,” which is incorporated by reference as if the contents of which are set forth herein. As stated in 3GPP TR 23.708, with respect to the SCEF, “The exposure of services by the network creates a ‘toolbox’ of capabilities that, with proper authorization, can be used, for example, to retrieve information, to request specific services, to receive notifications, to request the setting of specific parameters, etc.”
As further described in 3GPP TR 23.708, the SCEF is part of the “trust domain” in the sense that the core network will consider it a trusted entity with a secure connection to the core network. The SCEF, however, may be owned by a third party. The design of the interface between the SCEF and the core network should take ownership of the SCEF into account. For example, it might not be desirable to expose information, such as International Mobile Subscriber Identities (IMSI's), on this interface. As shown in FIG. 1, applications 104 can access application programming interfaces (API's). In accordance with the example, a service layer, a common services entity (CSE), and a service capability server (SCS) can be represented by one of the applications 104.
Referring now to FIG. 2, an example architecture for a local IP access (LIPA) or a Selected IP Traffic Offload (SIPTO) is shown. FIG. 2 is reproduced from 3GPP Technical Specification (TS) 23.401, “General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access,” which is incorporated by reference as if its contents are set forth herein. With respect to embodiments described herein, the HeNB 202 shown in FIG. 2 may also represent an eNB or small cell, which may be referred to collectively as a eNB/small cell. The L-GW 204 may be associated with a single eNB/Small Cell or it may be deployed in a Small Cell Network and connected to multiple eNB's/Small Cells. As shown, the L-GW 204 appears like a combined Serving Gateway (S-GW)/Packet Data Network (PDN) Gateway (P-GW) to the UE 206. The L-GW 204 is an IP data network anchor, which may be referred to generally as a local network anchor. The UE 206 may request to establish an LIPA PDN connection with the L-GW instead of a regular PDN connection with the S-GW/P-GW. The L-GW is deployed in the Local IP Network, which is geographically associated with the eNB/Small Cell Location. Thus, local IP traffic associated with the UE 206 can be routed more directly to/from the local services that it wishes to access. This may be an efficient alternative to routing the data through the core network and back into the local network. Similar to the P-GW, the L-GW 204 may provide various functions such as, for example, UE IP Address Allocation, DHCPv4 (server and client) and DHCPv6 (client and server) functions, Packet Screening and Neighbor Discovery for IPv6 Functionality that is defined in RFC 4861, Neighbor Discovery for IP version 6 (IPv6). Additionally, the L-GW 204 may support Evolved Packet System (EPS) Connection Management (ECM)-IDLE mode downlink packet buffering and ECM-Connected mode direct tunneling towards the HeNB 202.
Turning now to Selected IP Traffic Offload (SIPTO), SIPTO is described in Section 4.3.15a.1 of 3GPP TS 23.401. SIPTO generally refers to the case in which IP traffic is routed to an IP network without it traversing the mobile operator's network. For example, this may be achieved when the UE 206 establishes a PDN connection with the L-GW 204 that is colocated with the (H)eNB 202/Small Cell or a standalone L-GW function. With respect to SIPTO at the Local Network with a stand-alone GW (e.g., with S-GW and L-GW colocated) function, this type of SIPTO is described in section 4.3.15a.2 of 3GPP TS 23.401. In this type of L-GW deployment, the L-GW 204 is a standalone function and may serve multiple eNBs/Small Cells. A Local Home Network ID is associated with the L-GW 204. The eNB/Small Cells inform the Mobile Management Entity (MME) 208 that the L-GW 204 is accessible, and identify the L-GW 204 with the Local Home Network ID.
With respect to SIPTO at the Local Network with the L-GW 204 colocated with the (H)eNB 202, this type of SIPTO is described in section 4.3.15a.3 of reference 3GPP TS 23.401. In this type of L-GW deployment, the L-GW 204 is collocated with the (H)eNB 202. A Local gateway (GW) Address is associated with the L-GW 204. The eNB/Small Cells inform the MME 208 that the L-GW 204 is accessible, and identify the L-GW 204 with the Local GW Address.
Turning now to device triggering, a use case is considered in which an Application Server (AS) wants to communicate with a device application or a device service layer, but the device has no IP address or the Application Server does not know the device's IP address. Examples of Application Servers include, without limitation, a Service Layer, a SCS, an Infrastructure Node (IN)-CSE, or a Middle Node (MN)-CSE. A device trigger refers to a message that is initiated by an Application Server and sent to a device, usually over the control plane. Because it is sent over the control plane, an IP address is not needed to address the device. The trigger is sent to an external 3GPP identifier, such as an MSISDN or a URI for example. Device triggers can be used to send small amounts of application or device service layer data from an Application Server to a UE. A small amount of data can be sent to an application when no response is expected. For example, an Application Server can use a device trigger to instruct a sensor to turn on. If the Application Server expects no response, then no IP connection would be required. Device triggers can also be used to instruct a device application, or service layer, to initiate communications with the Application Server. In some cases, if an Application Server wishes to address a Machine Type Communication (MTC) device application that does not have an IP address, a device trigger is required.
A trigger may be delivered to an MTC device application that already has an IP address. For example, an Application Server may wish to establish a connection with an MTC device application, but the Application Server might not know the device's IP address or the Application Server might be unsure of whether the MTC device has an IP address.
With respect to X2 handover, in E-UTRAN, the eNB's can perform direct handover via the direct interface (known as X2 interface) between eNodeBs. In the X2-based handover (HO) procedure, which is described in oneM2M TS-0001, the source eNodeB and the target eNodeB prepare and execute the HO procedure. At the end of the HO execution, the target eNodeB requests the MME to switch the downlink data path from the source eNodeB to the target eNodeB. The MME in turn requests the serving GW to switch the data path toward the new eNodeB.
With respect to S1 handover procedures, which are described in 3GPP TS 23.401, an S1-based HO procedure may be used when the X2 procedure cannot be used. For example, the S1 based HO procedure may be used when there is no X2 interface between the source and target eNodeB's, or when the target eNodeB requires that a different MME and/or S-GW be used. The S1 procedure may be initiated when the eNodeB sends a handover required message to the MME via the S1-MME reference point.
With respect to Non-Access Stratum (NAS) Signaling, NAS signaling between the UE and MME is described in 3GPP TS 24.301, “Non-Access Stratum (NAS) protocol for Evolved Packet System (EPS)”; Stage 3, which is incorporated by reference as if its contents are set forth herein. As described in 3GPP TS 24.301, the NAS signaling between the UE and MME traverses the eNodeB/Small Cell, but it is usually ciphered and always integrity protected so that it cannot be modified or altered by the eNodeB/Small Cell. As further described in 3GPP TS 24.301, the eNodeB/Small Cell may append information to an NAS message, but may not modify or inspect the message itself.
Referring now to FIG. 3, an example M2M service layer is shown. Service Layers are generally a type of message bus or middleware that defines how services interact with applications and other services. A given Service Layer protocol may bind to a set of transport layer protocol(s). The oneM2M Service Layer is organized as a set of common functions (or service capabilities), an instantiation of which is referred to as a Common Services Entity (CSE). The oneM2M Service Layer is further described in oneM2M TS-0001, “Functional Architecture,” which is incorporated by reference as if its contents are set forth herein. The common functions are exposed via the Mca, Mcc and Mcn reference points as shown in FIGS. 3 and 4. FIG. 4 also depicts the Msc reference point. The Msc reference point specifies a set of interactions between the Service Capabilities of different Service Components. The realization of the interaction between the Services Capabilities is implementation specific, as described in oneM2M TS-0007, “Service Component Architecture,” which is incorporated by reference as if its contents are set forth herein.
Referring also to FIG. 4, the Mca reference point designates communication flows between an Application Entity (AE) and a CSE, and the Mcc reference point designates communication flows between two CSEs in the same M2M Service Provider domain. Communications across Mca and Mcc take place via paired Request/Response messages, wherein each request performs a specific RESTful operation (e.g., Create, Retrieve, Update, and Delete) upon a resource hosted on the targeted CSE. The Mcc′ reference point is used between CSEs located in the Infrastructure Domain of different M2M SPs. The Mcn reference point is used between a CSE and an underlying Network Services Entity (NSE) for services other than transport and connectivity. CSEs are hosted on architectural entities referred to as “nodes”. A node generally refers to a functional entity that contains a) one CSE and zero or more AEs, or b) one or more AEs. The oneM2M architecture makes no assumptions about the underlying platform and protocols that are used to pass messages on the Mcc, Mca, Mcc′, and Mcn reference points. For example, the services that are provided by CSE's may vary from a temperature sensor service that is implemented on a low cost device to a billing system that is deployed on a large network server. Thus, the architecture is well suited for utilizing a messaging protocol.
In current approaches to M2M architectures, as described above, no interworking API's are exposed to the Service Layers that are in the local network. Thus, a service layer might not able to make various requests including, for example, that devices be triggered, that the service layer receive notifications when devices are connected to the network, and that the service layer receive notifications when devices are no longer connected to the network.